Security|Update Registry entry

Update the contents of one or more fields in the current record when the record is saved if a condition is met (a given value is in a field in the current record). Often (but not exclusively) used to modify Record Level Security security fields.

Note: This functionality is available in EMu 4.1 or later. Texpress 8.3.006 (or later) is required.

The Security Update Registry entry allows the contents of one or more fields to be modified whenever a record is saved (inserted or modified) based on the value in a field in the current record. Although any fields may be updated in this way, the Record Level Security (RLS) fields:

  • SecCanDisplay
  • SecCanEdit
  • SecCanDelete

are particularly useful as updating these allows the record security to be modified if a condition in the current record changes.

The database server applies the Security|Update settings whenever a record is saved (i.e. for all insertions and updates). The entries are applied after assignment expressions have been executed and before validation is run. This means that assignment expressions may be used to build a composite value that may be tested by Security|Update settings. For example, it is possible to concatenate two fields into one that may then be checked.

It is also possible to apply sophisticated formula to calculate a field to be checked. For example, you may want to set Security|Update Registry entries based on a range of valuations for an object. You could use an assignment expression to set a value in a field based on the ranges:

Range

 Value
$0 - $1000 Cheap
$1001 - $10000 Average
$10001 - Pricey

You may then use the values, Cheap, Average and Pricey in Security|Update Registry entries.

Note that you cannot use validation code to compute values as the Security|Update entries are applied before validation code is executed.

Usage

This Registry entry can be assigned to users and groups:

Key User User Group Group Group Group
Key 1 User User Group Group Group Group
Key 2 user user group group Default Default
Key 3 Table Table Table Table Table Table
Key 4 table Default table Default table Default
Key 5 Security
Key 6 Update
Key 7 column
Key 8 value
Value settings
User user Table table Security Update column value settings
User user Table Default Security Update column value settings
Group group Table table Security Update column value settings
Group group Table Default Security Update column value settings
Group Default Table table Security Update column value settings
Group Default Table Default Security Update column value settings

where:

column

defines which field should be consulted to look for a matching value.

When referencing an attachment field in a Security|Update Registry entry, it is necessary to use a field's Link Column name and a record's IRN. For example:

Key Setting Description
Key 1 Group  
Key 2 Admin  
Key 3 Table  
Key 4 ecatalogue  
Key 5 Security  
Key 6 Update  
Key 7 LocCurrentLocationRef The attachment field is referenced as Key 7.
Key 8 9800 A record's IRN is required at Key 8.
Value SecRecordStatus=Deaccession  

When an attachment field is referenced as the Value, it is in the format Link Column name=IRN:

Key Setting
Key 1 Group
Key 2 Admin
Key 3 Table
Key 4 ecatalogue
Key 5 Security
Key 6 Update
Key 7 SecRecordStatus
Key 8 ^Deaccession$
Value LocCurrentLocationRef=9800

value

is an EMu based search pattern.

If there is a match of the data in column with the value query, then the Registry entry is used and settings is applied.

Note: If column contains a table of values, each entry is checked against value.

Since value is a pattern, particular attention must be paid if you want to match the complete contents of a field.

For example, to match Registration but not Pending Registration, the pattern ^Registration$ should be used. It is important to remember that value operates in the same way as an EMu search term.

All comparisons of value are case insensitive.
settings

is a semicolon separated list of assignments to columns that is applied if there is a match of the data in column with the value query.

The format of settings is:

column=[+/-]term:[+/-]term:...;column=[+/-]term:...

where:

column

is the name of the column to be modified.

term

is the value to be set in column.

  • If term is preceded by a plus symbol (+), the value is added to the existing list of values.
  • If term is preceded by a minus sign (-), the value is removed from the existing list of values.
  • If no symbol precedes a term, the current contents of column are removed and replaced with term.
  • If more than one term is supplied for a given column, separated by colons (:), each term is applied one after the other.
  • If more than one column is to be modified, each set of column settings is separated by a semicolon (;).

If you specify a Security|Update Registry entry to limit the display of a record to group Admin if Record Status is changed to Retired for example, it is necessary to specify a Security|Update Registry entry to account for Record Status changing from Retired to some other condition (Active or null for instance). If no Security|Update Registry entry is specified to account for the change, changing the Record Status from Retired to some other condition will not update the security of the record.

Why?

We've only told EMu what to do if Record Status = Retired; we haven't told EMu what to do if Record Status no longer =Retired.

What does this mean?

If we only specify a Security|Update Registry entry to limit the display of a record to group Admin when Record Status = Retired, changing Record Status to anything other than Retired will not make the record available to other users.

If we want Record Level Security to be adjusted so that users in group Admin are the only ones allowed to edit and delete records that have a record status of Retired, the following entry can be used:

Key Setting
Key 1 Group
Key 2 Default
Key 3 Table
Key 4 Default
Key 5 Security
Key 6 Update
Key 7 SecRecordStatus
Key 8 ^Retired$
Value SecCanEdit=Group Admin;SecCanDelete=Group Admin

Keys 7 and 8 indicate that the entry only applies where the SecRecordStatus column matches the pattern ^Retired$ (i.e. where the field contains Retired only). If this is not the case, then the Registry entry is ignored. Where a record does match, the SecCanEdit field is set to group Admin. As a leading plus or minus is not supplied, the contents of SecCanEdit are replaced with group Admin. A similar update occurs for SecCanDelete.

A more complex example would involve removing edit access for all users in groups Conservation and Storage when an object is deaccessioned. Let's assume that the column RecObjectStatus contains the word Deaccessioned for objects that are no longer part of our collection. A suitable Registry entry would be:

Key Setting
Key 1 Group
Key 2 Default
Key 3 Table
Key 4 ecatalogue
Key 5 Security
Key 6 Update
Key 7 RecObjectStatus
Key 8 ^Deaccessioned$
Value SecCanEdit=-Group Conservation:-Group Storage

Notice how the terms to set have a leading minus sign, indicating the term (in this case the group name) is to be removed from the field SecCanEdit.

A third example requires all records with an object valuation of High to have group Student removed and group Valuers added for both displaying and editing the record. The field containing the object valuation is ValValuationCode. A suitable Registry entry is:

Key Setting
Key 1 Group
Key 2 Default
Key 3 Table
Key 4 ecatalogue
Key 5 Security
Key 6 Update
Key 7 ValValuationCode
Key 8 ^High$
Value SecCanDisplay=-Group Student:+Group Valuers;SecCanEdit=-Group Student:+Group Valuers

Notice how more than one field may be updated with a single Registry entry. Note also:

  • If a term has a leading plus symbol and the term already appears in the field, it is not added again.
  • Similarly, if a term has a preceding minus and it does not appear in the field, it is ignored.

In this final example we restrict the display privilege for records that have not been approved for viewing on the intranet to groups Admin, Curator, Storage and Conservation. Once the record has been approved for viewing on the intranet we will allow all users to view the record. In this case two Registry entries are required:

  • The first restricts access for records not available on the intranet.
  • The second allows access to all users for record available on the intranet.

Suitable Registry entries are:

Key Setting
Key 1 Group
Key 2 Default
Key 3 Table
Key 4 ecatalogue
Key 5 Security
Key 6 Update
Key 7 AdmPublishWebPasswordFlag
Key 8 N
Value SecCanDisplay=Group Admin:+Group Curator:+Group Storage:+Group Conservation
Key Setting
Key 1 Group
Key 2 Default
Key 3 Table
Key 4 ecatalogue
Key 5 Security
Key 6 Update
Key 7 AdmPublishWebPasswordFlag
Key 8 Y
Value SecCanDisplay=Group Default

Notice how the first term in the first Registry entry (Group Admin) does not have a leading plus or minus, meaning it replaces the current contents of SecCanDisplay. The following terms require a leading plus symbol otherwise they will also clear the current contents rather than adding to the first term. The second Registry entry replaces the contents of SecCanDisplay with group Default (this allows access for everyone).

By using a combination of Registry entries it is possible to produce quite sophisticated and dynamic privilege changes.